Response to Office Action of: 3 March 2010 
Response Dated: 3 September 201 0 
Title: Mobile Payments System 



App. No.: 10/553,360 
Inventor: Davies et al. 
Examiner: Monfeldt, Sarah M 



REMARKS 



Claims 1-14, 16-30, 34, 35 and 37-45 are now pending in the case, in agreement 
with the Examiner's statement of claim status. 

Claim amendment 

While no amendments are made, applicant has included a Listing of Claims for 
the Examiner's convenience. 

Claim rejections - 35 USC §1 1 2 

The prior rejection of claim 37 as indefinite was not repeated and is believed to 
be overcome. 



The Examiner has made several obviousness rejections that start with Berardi 
'226 as the primary reference. 

The rejections are as follows: 

1. Claims 1-7, 9-12 and 38-43 are obvious over Berardi '226, Adam 710, 
Campisano '447 and Shore '662; 

2. Claim 8 is obvious over Berardi '226, Adam 710, Campisano '447, Shore 
'662 and Nguyen '361 ; 

3. Claim 13 is obvious over Berardi '226, Adam 710, Campisano '447, Shore 
'662 and Grunbok '603; 

4. Claims 44 and 45 are obvious over Berardi '226, Adam 710, Campisano 
'447, Shore '662 and Sohaei '308; 

5. Claims 14, 16-23 and 25 are obvious over Berardi '226, Adam 710, and 
Campisano '447; 

6. Claim 24 and 26-28 are obvious over Berardi '226, Adam 710, 
Campisano '447 and Grunbok '603; 

7. Claim 29 is obvious over Berardi '226, Adam 710, Campisano '447, 
Grunbok '603, Shore '662 and US Published application US 
2004/0015450 to Zingher ("Zingher '450"); 

8. Claim 30 is obvious over Berardi '226, Adam 710, Campisano '447, 
Grunbok '603, Shore '662; 



Claim rejections - 35 USC §103 
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9. Claim 34 is obvious over Grunbok '603 and Nguyen '361 ; 

10. Claim 35 is obvious over Grunbok '603, Nguyen '361 and Shore '662; 

1 1 . Claim 37 is rejected as obvious over Adam 71 0 and Nguyen '361 . 

For the convenience of everyone concerned, applicant notes that there are 
presently 5 independent claims. They are listed as follows, with their currently 
dependent claims in parentheses: 

Claim 1 (claims 2-13, 38-45); 

Claim 14 (claims 16-25); 

Claim 26 (claims 27-30); 

Claim 34 (claim 35); and 

Claim 37 (no dependents). 

Applicant traverses each and every rejection. 

Preliminarily, however, applicant repeats an ongoing traverse on the basis that 
the Examiner has not provided any articulated reasoning as to why any of the above 
rejections that involve at least three references are indicative of anything other than 
hindsight, based upon the claims. 

Berardi '226, Adam '710, Campisano '447 and Shore '662 

Applicant addresses this rejection, made at item 7, page 2 of the Detailed Action. 
Repeating the argument above about lack of articulated reasoning, applicant believe the 
Examiner has not presented any articulated reasoning why the skilled person would be 
so motivated or made any other response to this argument. The Office Action 
addresses only the question of whether the different features of claim 1 can be 
separately found in the four different documents, and not the question why the skilled 
person would be motivated to combine the documents. 

Applicant has previously argued that the feature of claim 1 of "said at least one 
server device being adapted to store a second part of the authorisation data comprising 
financial data relating to a user of the mobile device in association with said first part of 
the authorization data and the mobile device identity information and, in response to 
receiving said first part of the authorisation data and the mobile device identity 
information, to verify said authorisation data and to retrieve said second part of the 
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authorisation data comprising the user's financial data to complete a transaction" is not 
taught by Adam 710 in view of Campisano '447. 

Item 7 accepts that this feature is not disclosed in Beradi '226 either, and argues 
that it would be obvious to add this feature to Berardi '226 in view of Adam '71 0 and 
Campisano '447. 

In the Examiner's response to arguments in the present Office Action (Item 19, at 
p 42), the Examiner states that "Campisano shows the linking of (1) an identification, i.e. 
phone number, to (2) a second part, i.e. a credit card number, and (3) a first part, i.e. 
corresponding PIN," with (1) the phone number of Campisano '447 being related to the 
phone identity as claimed and as shown by Berardi '226, (2) the PIN of Campisano '447 
being related to the first authorization as claimed and as shown by Berardi '226, (3) the 
card number of Campisano '447 being related to the second part of the authorization 
and as shown by Adam '710, i.e. customers details, balance, credit limitations which are 
associated with the customer's (or his mobile phone) identification details. The 
Examiner cites Campisano '447 at Col.1 , lines 46-51 , Col. 2, lines 22-24, 32-34 and 42- 
43 and Col. 4, lines 6-1 1 , 26-30 and 42-45. 

The Examiner refers to elements in Berardi '226 and Adam '710 which are 
asserted to correspond to the elements of Campisano '447. However, the assertions 
that (1 ) the phone number of Campisano '447 is related to the phone identity of Berardi 
'226, (2) that the PIN of Campisano '447 is related to the first authorization of Berardi 
'226, and (3) that the card number of Campisano '447 is related to the second part of 
the authorization of Adam '710, do not affect the teaching of Campisano '447 regarding 
the relationship between these elements. Campisano '447 clearly teaches the linking or 
association of the second part of the authorisation data comprising financial data 
relating to a user of the mobile device in association with said first part of the 
authorization data and the mobile device identity information. 

As explained in the 3 September 2010 response, most of the above referenced 
parts of Campisano '447 teach that a user home telephone number can be used as a 
user identifier in a payment system in which a user provides their home phone number 
and a PIN in order to make a payment, and that a user can select multiple PINs each 
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corresponding to different credit cards. Another part of Campisano '447, referenced in 
the Advisory Action, merely restates this teaching. The referenced part of Campisano 
'447 at Col. 4, lines 26-30, teaches that a user home phone number \n a database can 
be linked to a credit card number. 

Campisano '447 addresses the drawback of existing credit cards, which is that 
they do not allow purchases to be made without the actual card, either in person or over 
the telephone (Col 1 , lines 1 5-21 ), and attempts to prevent fraud by the misuse of lost or 
stolen credit cards (Col 1 , lines 29-33, and Col 4, lines 18-25). To do this, Campisano 
'447 "provides a system for assigning an alias for a cardholder's credit card number 
using an easy to remember number" (CoM , lines 40-42), and teaches in particular that 
this easy to remember number should be a user's home telephone number (Col 2, lines 
19-24). 

However, the above identified feature of claim 1 does not merely refer to a 
telephone number or a user telephone number. Instead, the wording of this feature of 
claim 1 explicitly refers to "mobile device identity information". The identified feature of 
claim 1 explicitly requires, not just a telephone number, but the identity information of 
the particular mobile device from which the first part of the authorisation data was 
received, as specified at lines 8-1 1 , which state "adapted to receive from a mobile 
device a first part of the authorisation data and identity information for said mobile 
device via its input and to send said first part of the authorization data and the mobile 
device identity information to the at least one server". 

Thus, claim 1 clearly and explicitly requires that the first part of the authorisation 
data is received from a mobile device together with identity information for the mobile 
device, that the first part of the authorization data and the mobile device identity 
information are sent to a server, "the server device being adapted to store a second part 
of the authorisation data comprising financial data relating to a user of the mobile device 
in association with said first part of the authorization data and the mobile device identity 
information and, in response to receiving said first part of the authorisation data and the 
mobile device identity information, to verify said authorisation data and to retrieve said 



13 



Response to Office Action of: 3 March 2010 
Response Dated: 3 September 201 0 
Title: Mobile Payments System 



App. No.: 10/553,360 
Inventor: Davies et al. 
Examiner: Monfeldt, Sarah M 



second part of the authorisation data comprising the user's financial data to complete a 
transaction". 

The referenced parts of Campisano '447 teach that a user could provide their 
home telephone number as an alias in place of a credit card number when carrying out 
transactions at a point of purchase location which may be "any store that accepts credit 
cards" or "Any telephone" (Col 2, lines 1 5-1 9). Campisano '447 explains that when 
placing a telephone order, which may be from any telephone, "Instead of ... in the case 
of a telephone order providing the card number and expiration date, the cardmember 
will enter the cardmember's ten-digit home telephone number and PIN" (Col 2, lines 19- 
23), and then, to validate the transaction, "The validation process should be fairly quick 
and will then retrieve the credit card linked to the phone number and PIN the cardholder 
has provided" (Col 2, lines 32-34). 

Thus, Campisano '447 teaches only that an alias number provided by a user, 
which may be their home telephone number, should be linked to a credit card number 
and a PIN. Campisano '447 does not teach or suggest that the identity of the telephone 
from which the user is calling (which Campisano '447 teaches may be "Any telephone"), 
should be recorded or linked to other data, or is of any other significance. Accordingly, 
even if the credit card number and PIN of Campisano '447 are regarded as being a first 
part of authorisation data and a second part of authorisation data respectively, 
Campisano '447 still does not teach or suggest storing "a second part of the 
authorisation data comprising financial data relating to a user of the mobile device in 
association with said first part of the authorization data and the mobile device identity 
information", where the mobile device identity information is mobile device identity 
information of the mobile device from which the first part of the authorisation data was 
received, as required by claim 1 , or teach that "in response to receiving said first part of 
the authorisation data and the mobile device identity information, to verify said 
authorisation data and to retrieve said second part of the authorisation data comprising 
the user's financial data to complete a transaction", where the mobile device identity 
information is mobile device identity information of the mobile device from which the first 
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part of the authorisation data was received, although this is expressly required by claim 
1. 

As a result, Campisano '447 fails to teach the relationship between the first part 
of the authorisation data, the mobile device identity information and the second part of 
the authorisation data defined in the identified features of "a second part of the 
authorisation data comprising financial data relating to a user of the mobile device in 
association with said first part of the authorization data and the mobile device identity 
information" and "in response to receiving said first part of the authorisation data and 
the mobile device identity information, to verify said authorisation data and to retrieve 
said second part of the authorisation data comprising the user's financial data to 
complete a transaction". 

Because Campisano '447 fails to disclose these features, the Examiner's 
proposed combination to "expand the apparatus of Berardi '226 to include the CSC to 
administer accounts of merchants and customers as taught by Adam et al. and cross 
linking of a card holders phone number to the credit card number and providing the 
customer with a corresponding PIN", according to the teaching of Campisano '447, 
would not provide the feature of claim 1 of "said at least one server device being 
adapted to store a second part of the authorisation data comprising financial data 
relating to a user of the mobile device in association with said first part of the 
authorization data and the mobile device identity information and, in response to 
receiving said first part of the authorisation data and the mobile device identity 
information, to verify said authorisation data and to retrieve said second part of the 
authorisation data comprising the user's financial data to complete a transaction". 

On page 6 of the Office Action, the Examiner suggests that "one of ordinary skill 
in the art at the time of the invention would have been motivated to expand the 
apparatus of Berardi '226 in this way since it allows the system to check for any 
problems or inconsistencies with respect to the merchant and/or the customer 
identification or the customer's balance (see at least paragraph [0130] of Adam et al.), 
since it allows for the customer to provide the PIN corresponding the card he or she 
wishes to charge the purchase on (see at least col. 4, II. 6-1 1 of Campisano) and since 
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the validation process should be fierily quick and should retrieve the credit card linked to 
the phone number and PIN the card holder provided (see at least col. 2, II. 32-35 of 
Campisano)". 

Applicant responds that the referenced parts of Campisano '447 do not teach the 
relationship between the first part of the authorisation data, the mobile device identity 
information and the second part of the authorisation data defined in the identified 
features of claim 1 . Campisano '447 only teaches the use of a phone number as an 
alias by the user. It never teaches that the phone number of the phone being used has 
any significance. As explained above Campisano '447 clearly teaches that "any phone" 
may be used regardless of the phone number provided by the user. 

The features referred to by the Examiner of "allows for the customer to provide 
the PIN corresponding the card he or she wishes to charge the purchase on" and "the 
validation process should be fierily quick and should retrieve the credit card linked to the 
phone number and PIN the card holder provided" are provided by Campisano '447. In 
view of that, these features fail to provide a reason for one of skill in the art to make any 
changes in Campisano '447 to provide the features of claim 1 of "said at least one 
server device being adapted to store a second part of the authorisation data comprising 
financial data relating to a user of the mobile device in association with said first part of 
the authorization data and the mobile device identity information and, in response to 
receiving said first part of the authorisation data and the mobile device identity 
information, to verify said authorisation data and to retrieve said second part of the 
authorisation data comprising the user's financial data to complete a transaction". 
Further, the Examiner suggests no reason. 

Accordingly, the Examiner has failed to make a prima facie case that claim 1 is 
obvious in view of the asserted combination of cited art, so claim 1 is allowable and the 
rejection should be withdrawn. 

Claims 2-1 3 and 38-45 are allowable as proper dependent claims. Applicant 
does not specifically address the rejections of claims 8 (Berardi '226, Adam '710, 
Campisano '447, Shore '662 and Nguyen '361), 13 (Berardi '226, Adam '710, 
Campisano '447, Shore '662 and Grunbok '603) or 44 and 45 (Berardi '226, Adam '710, 
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Campisano '447, Shore '662 and Sohaei '308) because none of the additional 
references used provide the missing teaching. 

Berardi '226, Adam '710 and Campisano '447 

The Examiner has repeated a rejection of claims 14, 16-23 and 25 as obvious 
over Berardi '226, in view of Adam 710 and Campisano '447. 

Independent claim 14 includes corresponding features to those discussed 
regarding claim 1, especially regarding the failure of Campisano '47 to teach the use of 
the mobile device identity number, so claim 14 is allowable for the same reasons as 
claim 1 . 

Claims 16-23 and 25 are all allowable as proper dependent claims, based on the 
allowability of claim 14 obvious because they depend from a claim that is not obvious. 

The rejection of claim 24, based on the above combination plus Grunbok '603, is 
traversed because Grunbok '603 does not provide the teaching missing from the other 
references with regard to claim 14, so it is also allowable. 

Berardi '226, Adam '710, Campisano '447 and Grunbok '603 

The Examiner has repeated a rejection of claims 26-28 as obvious over Berardi 
'226, Adam '710, Campisano '447 and Grunbok '603. The Examiner has made a new 
rejection of claim 29 as obvious over these same references plus the addition of US 
published application US 2004/0015450 to Zingher, and has repeated a rejection of 
claim 30 as obvious over the claim 26 art plus Shore '662. 

Respectfully, claim 26 includes corresponding features to those discussed 
regarding claim 1 and, as argued above, the Examiner has failed to demonstrate with 
articulated reasoning the reasons why one would substitute the use of the identifier of a 
mobile telephone being used for the use of a home telephone number, as Campisano 
'447 teaches. Accordingly, claim 26 is allowable and the rejection should be 
withdrawn. 

Claims 27-30 are allowable as proper dependent claims, even with the additional 
references cited, as none of the additional references provide the teaching that is 
needed to render claim 26 obvious. 
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Grunbok '603 and Nguyen '361 

The Examiner has rejected independent Claim 34 as obvious over Grunbok '603 
and Nguyen '361 and uses Shore '662 for the further rejection of Claim 35. 

The Examiner suggests that Grunbok '603 discloses all features of claim 34 
except for the feature of "a data store for storing user specific data in association with at 
least one of said identifiers", and further suggests that this feature is disclosed by 
Nguyen '361. 

Respectfully, this analysis is incorrect. Grunbok '603 does not disclose the 
feature of "a price list computer program for processing a price list arising from a 
transaction... the price list processor is adapted to process a price list arising from a 
transaction by applying user specific data," at the cited location. Applicant respectfully 
asserts that this portion of Grunbok '603 teaches only how to arrange payment of a 
transaction. 

Grunbok '603 does not disclose processing a price list arising from a transaction 
by applying user specific data. Grunbok '603, at Col 6, lines 20-31, and Col 5, lines 10- 
33, teaches only how the cost of a purchase can be met by taking funds from a plurality 
of different user accounts. There is no teaching whatsoever that a price list of a 
transaction can be processed in any way, and certainly no teaching that the price list 
arising from a transaction can be processed by applying user specific data according to 
the feature of claim 34. 

Even if arranging payment of a purchase according to Grunbok '603 was 
regarded as teaching "process a price list" it cannot reasonably be regarded as teaching 
"process a price list... by applying user specific data" according to claim 34. 

An example of processing of a price list of a transaction by applying user specific 
data is for a loyalty scheme in which a user may have a discount arising from their 
purchasing history, as explained in the specification at page 5, line 31 , to page 6, line 2. 
However, it is stressed that this is merely an example and that Grunbok '603 does not 
teach or suggest that a price list of a transaction can be processed in any way by 
applying user specific data. 
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This feature is also not taught by Nguyen '361. Although Nguyen '361 teaches a 
data store, there is nothing in the specification to teach or suggest in any way that the 
price list arising from a transaction can be processed by applying user specific data. 

As the applicant as argued in a previous response, claim 34 is allowable over the 
cited art and the rejection should be withdrawn. 

Claim 35 is allowable as a proper dependent claim and the further citation of 
Shore '662 does not provide the elements missing from teh rejection of claim 34. 

Adam '710 and Nguyen '361 

The Examiner has repeated a rejection of independent claim 37, which has no 
dependent claims, as being obvious over Adam '710 and Nguyen '361. 

The Examiner accepts that the features of claim 37 of a communication device 
"having an address in a public network" and of "transmitting the generated receipt to a 
communication device having a different address in a public network" are not taught by 
Adam 710, but the Examiner suggests that these features are taught by Nguyen, 
particularly at paragraphs [0006] and [0018]. 

First, the applicant asserts that the Examiner has located Nguyen '361 and its 
teachings in a "hindsight" manner to respond to the language of claim 37 and has not 
articulated why one of ordinary skill would have incentive to "expand the apparatus of 
Adam 710" in the manner suggested. 

Applicant also respectfully submits that nothing in either of these cited references 
teaches the feature of "transmitting the generated receipt to a communication device 
having a different address in a public network", as required in claim 37. In particular, it is 
submitted that there is nothing in Nguyen '361 to suggest in any way that the "temporary 
mobile address" in referenced paragraph [0018] corresponds to "a communication 
device having a different address in a public network" to the "address in the public 
network of the communication device identified in the received transaction information" 
according to claim 37. 

At paragraph [0018], Nguyen '361 teaches that the "temporary mobile device 
address... temporarily overrides the pre-registered mobile device address". This will 
cause the "response on the outcome of the transaction" according to paragraph [0016] 
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to be sent to the temporary mobile device address and not to the pre-registered mobile 
device address. However, it does not follow from this that the response will be sent to "a 
communication device having a different address in a public network" as required in 
claim 37, because there is nothing in Nguyen to teach or suggest in any way that the 
transaction is based on received transaction information identifying the pre-registered 
mobile device address. Paragraph [0016] of Nguyen '361 teaches that the transaction 
"is initiated from a card reader 101 , an ATM 102, a website 103, or from a bank slip 
such as a written check, deposit slip, withdraw slip, fund transfer slip 104". This listing, 
and the teaching elsewhere in Nguyen '361 , does not make any reference to the 
transaction being initiated by, or in any other way based on, transaction information 
from a communication device. 

Further, paragraph [0018] of Nguyen '361 teaches that the pre-registered mobile 
device address has been collected and stored "When the account owner registers for 
the delivery service". There is no teaching that this address is related in any way to a 
communication device which has provided transaction information. 

While the benefit of hindsight might suggest that the temporary mobile device 
address feature of Nguyen '361 could be used to send a response to a communication 
device having a different address, there is no express teaching in Nguyen '361 to 
suggest that this should or could be done. 

Accordingly, claim 37 cannot be arrived at by combining the cited art so that 
claim 34 is not obvious and is patentable. 



Respectfully submitted, 



Date: 15 September 2011 



By: /Stephen L. Grant, Reg No 33,390/ 



Stephen L. Grant 
Attorney for Applicants 
Registration No. 33,390 
Standley Law Group LLP 
6300 Riverside Dr 
Dublin, Ohio 43017-5043 
Telephone: (614) 792-5555 
Facsimile: (614) 792-5536 
E-mail:sgrant@standleyllp.com 
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